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An Interface Identifier (ID) Hello Option for PIM 
Abstract 
This document defines a new PIM Hello option to advertise an 
Interface Identifier that can be used by PIM protocols to uniquely 
identify an interface of a neighboring router. 
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1. Introduction 


This document defines a new option for use in PIM Hello messages 
[RFC4601] to carry an Interface Identifier. A router generates 
identifiers for each of its PIM-enabled interfaces such that each 
interface has a different identifier. The identifiers can optionally 
be generated such that they are unique within, e.g., an 
administrative domain. 


An example where this Interface Identifier can be used is with PIM 
over Reliable Transport (PORT) [PIM-PORT], where a single Transport 
connection is used between two routers that have multiple interfaces 
connecting them. If these interfaces have unnumbered or IPv6 link- 
local addresses, the Interface Identifier included in the PORT Join/ 
Prune message will identify with which interface the message is 
associated. For PORT, the Router Identifier is not needed, and it 
can be set to zero. 


All multi-byte integers in this specification are transmitted in 
network byte order (i.e., most significant byte first). 


1.1. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Interface Identifier Option 


The Interface Identifier option is used to identify the interface of 
a neighboring router through which a PIM Hello [RFC4601] was sent. 
This allows PIM protocols to refer to, or identify, a particular 
interface on a neighboring router. 
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The Interface Identifier option need only be included in PIM Hello 
messages if the router supports protocols that require it. An 
implementation MAY choose to always include it. The usage of the 
Interface Identifier and the uniqueness requirements are left to the 
specifications of the PIM protocols that implement it. It is assumed 
that different protocols have different minimum requirements for 
stability and uniqueness of the Interface Identifier but that they 
have no maximum requirement. When specified, these protocols should 
indicate what their minimum requirements are. 


The Interface Identifier consists of 64 bits. The lower 32 bits form 
a Local Interface Identifier, and the high 32 bits form a Router 
Identifier. 

2.1. Local Interface Identifier 


The 32-bit Local Interface Identifier is selected such that it is 
unique among the router’s PIM-enabled interfaces. That is, there 
MUST NOT be two PIM interfaces with the same Local Interface 
Identifier. While an interface is up, the Identifier MUST always be 
the same once it has been allocated. If an interface goes down and 
comes up, the router SHOULD use the same Identifier. If a node goes 
down and comes up again, the Identifier for each interface MAY 
change. Many systems make use of an ifIndex [RFC2863] as a Local 
Interface Identifier. 


The Local Interface Identifier MUST be non-zero. The reason for this 
is that some protocols may have messages that optionally reference an 
Interface Identifier, and they may use the value of 0 to show that no 
Interface Identifier is being referenced. Note that the value of 0 
is not a valid ifIndex as defined in [RFC2863]. 


2.2. Router Identifier 


The 32-bit Router Identifier may be used to uniquely identify the 
router. The requirements for the scope in which the Router 
Identifier needs to be unique depend on the protocols that utilize 
it. It may need to be unique within some administrative domain, or 
it may possibly be globally unique. 


A router implementation selects a Router Identifier according to a 
configured policy that defines the uniqueness scope. Thus, an 
implementation MAY be configured to choose an IPv4 unicast address 
assigned to the router as the Router Identifier, but the 
implementation MUST allow the identifier to be configured manually. 
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Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other 
protocols that make use of 32-bit identifiers for routers. Provided 
that the stability and uniqueness requirements of the protocols that 
make use of the Router Identifier are met, an implementation MAY use 
the same identifier used by other protocols. 


The value 0 has a special meaning for the Router Identifier. It 
means that no Router Identifier is used. If a router only supports 
protocols that require the Interface Identifier to be unique for one 
router (only making use of the Local Interface Identifier), then the 
implementation MAY set the Router Identifier to zero. 


3. Message Format 
Option Type: Interface Identifier 


0 1 2 3 

0 12 3 45 6789012345678 9O1 2345678 901 
ma EE EE N EE EE H 
| Type = 31 | Length = 8 | 
deden 
| Router Identifier | 
EE EE toto derde 
| Local Interface Identifier 
EE EE EE 


Allocated Hello Type values can be found in [HELLO-OPT]. 


Length: In bytes for the value part of the Type/Length/Value 
encoding. The Interface Identifier will be 8 bytes long. 


Router Identifier: The Router Identifier is a 4-byte identifier 
uniquely identifying the router within some scope. It MAY be 0 
when no protocols require a Router Identifier. The field MUST 
contain a valid Router Identifier or the value zero. 


Local Interface Identifier: The Local Interface Identifier is a 
4-byte identifier that is unique among all PIM-enabled interfaces 
on a router. 


4. Security Considerations 


The Interface Identifier is included in PIM Hello messages. See 
[RFC4601] for security considerations regarding PIM Hello messages. 
In particular, PIM Hello messages may be forged and include an 
arbitrary Interface Identifier, or the Interface Identifier may be 
intentionally omitted. The effects of this depend on how the 
Interface Identifier is used by other protocols. 
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5. IANA Considerations 


IANA has assigned the value 31 for the Interface ID PIM-Hello option 
defined in this document. 
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